A user interface is crucial for the productive use of a device. The need for carefully designed and preferably customizable user interfaces is well recognized. However, features that allow humans to best relate to information and to have information presented visually, with a layout that draws attention to the most important information and with additional tactile and audio effects are not readily implemented to support communication protocols such as telnet.
Terminal emulation (telnet) is traditionally a text-only medium. Support for sounds is limited to beeps, with custom efforts required to support any sounds more complex than that.
Most operators prefer receiving visual and sound information to merely being responsible for reading information exclusively as text. Further, being able to enter data by speaking to the computer will simplify, enhance and speed up the use of computers well beyond the current usage. One protocol that is still useful for inter-computer communications is the telnet protocol. While more secure protocols are possible, the simplicity of the telnet has managed to make it relevant despite its age and certain security related drawbacks.
The telnet protocol was introduced to provide a fairly general, bi-directional, eight-bit oriented communications facility. Primarily, it allows a standard method of interfacing between terminal devices and between processes. The protocol is often used for terminal-terminal communication and process-process communication (distributed computation). A telnet connection (or session) typically is a Transmission Control Protocol (TCP) connection carrying data with interspersed telnet control information. A series of communications called scripts are typically passed over a telnet connection as part of the data. The telnet Protocol also allows for a “Network Virtual Terminal” and negotiated options.
Upon establishing a telnet session, each end is assumed to originate and terminate at an imaginary “Network Virtual Terminal” providing a standard, network-wide, intermediate representation of a terminal. As a result there is no need for “server” and “user” or “client” hosts to track the characteristics of various terminals and terminal handling conventions. All telnet participants map their local device characteristics and conventions so as to appear to be dealing with an NVT over the network. Thus, each can assume a similar mapping by the other party.
The provision for negotiated options allows hosts to provide additional services over and above those available within a minimal NVT. Independent of, but structured within the telnet Protocol are various “options” that may be used with a “DO, DON'T, WILL, WON'T” structure to allow negotiations directed to permitting use of a more elaborate set of conventions for their telnet connection. Further, the terminal emulated may further enhance the user interface without affecting the other parties by adhering to the telnet protocol. Such options could include changing the character set, the echo mode, data security features, etc. The basic strategy for setting up the use of options is to have a party initiate a request that some option take effect if the option affects more than one party. The other party may then either accept or reject the request. If the request is accepted the option immediately takes effect.
A telnet session may be customized with a script. A script is a computer programming language that is interpreted (rather than requiring compilation) and can be typed directly from a keyboard. Unlike a script, commands in which are interpreted one at a time, programs are converted permanently into binary executables suitable for execution on a particular type of computer or processor. The chief benefit provided by a script is the reduction in the traditional edit-compile-link-run process. It should be noted that although scripting languages are interpreted, this does not exclude compilation. The significant ease in devising an interpreter over providing a compiler makes it easier to write interpreters for a scripting language.
Typically, each command in a script may be executed independently, resulting in stateless operation. In other words, once a scripting language command is executed, the processor can execute another command without having the already executed command affect the result. This almost natural property of a scripting language, however, can be modified to allow the ability to detect a state of interest. For instance a script supported by a telnet client may detect the text displayed on a screen, or even additional information not included in the telnet data stream. The information about a state may be embedded in the script data to allow retention of a state for some operations while executing the scripting language based routines in the customary manner. Additional commands may be provided to process and program embedded state information in such an implementation.
It should be noted that data within a script may have a peculiar structure requiring specially written code to handle the structure. Appropriately designed and deployed, scripts can help program applications, quickly automate repetitive tasks, and provide contextually relevant customization. Providing the appropriate scripts and implementations remain a challenge due to the complexity of a user interface and aspects of it that need customization.
Some terminal emulation types define “fields” that are used to submit information to the host. These are one or more regions of the screen set aside for user input. Because each field is defined independently, it can have different locations (on the screen), lengths, and unique flags to specify the type of data it expects. When the field information is supplied to the host, the location for the field is also included; the host can use this information to determine which field contained the data, and treat the data appropriately for that field.
It is also possible to identify fields by assigning them unique numbers or text strings. These numbers or text strings are referred to as “data identifiers”. This allows useful behavior such as knowing which field to assign a scanned barcode to based on a data identifier embedded in the barcode.
These data identifiers are traditionally specified by the server and sent to the client over the terminal emulation session. This allows the server's programmer(s) to create and change them as needed. However, it is not uncommon to find companies unwilling or unable to update their server application(s) that have been in use for years. So far, in the context of warehouse inventory systems a hand-held telnet client has been a relatively unintelligent device. Many companies use inventory tracking systems and are at the same time are unable or unwilling to modify their server applications. Accordingly, there is a need for providing the data identifier and speech recognition and voice functionality to the inventory tracking systems by implementing this functionality on the telnet clients as oppose to the servers.